Seed sample data in the Cosmos DB samples' 01-deploy-resources.sh - #56

Motivation

The samples are inconsistent about sample data. The SQL Database, MySQL, PostgreSQL, Blob Storage and Managed Identity samples seed sample activities when 01-deploy-resources.sh creates their data store, so the Vacation Planner opens with a list, while the Cosmos DB for NoSQL and Cosmos DB for MongoDB samples seeded nothing and opened empty. This pull request makes the two Cosmos DB samples, in Python and .NET, seed the same activities as the database samples.

Testing the MongoDB sample on Azure showed that it did not work there at all: az cosmosdb create --kind MongoDB --server-version 7.0 creates a 3.6 account, because the Azure CLI sends the version as a ServerVersion property, which the service ignores (2.91.0, and still on the azure-cli dev branch; az cosmosdb update --server-version has the same problem). PyMongo 4.17 and MongoDB.Driver 3.11, which the sample's apps use, refuse a 3.6 server, and so does mongosh. The script now sets the version itself.

The File Storage and in-cluster PostgreSQL samples keep seeding in 05-deploy-app.sh, by design: their data store only exists once the app is deployed (the Azure Files CSI driver creates the share when the claim binds, and the PostgreSQL server runs in the cluster).

Fixes SMF-1139

Changes

• samples/web-app-cosmosdb-nosql-api/{python,dotnet}/scripts/01-deploy-resources.sh: inserts the nine activities as items {id, username, activity, timestamp} for LOGIN_NAME, the shape the apps read and write, through the Cosmos DB REST API with curl: the Azure CLI has no command for items. Each request is signed with the primary master key (openssl), as Microsoft's access control page describes. An item id is the MD5 of the user and a fixed name, as in the MySQL sample, so a re-run inserts only the missing items (Cosmos DB answers 409 Conflict for an existing id). The activities are then queried back.
• samples/web-app-cosmosdb-mongodb-api/{python,dotnet}/scripts/01-deploy-resources.sh:
  • When the account reports a server version other than MONGODB_API_VERSION, sets serverVersion with az rest (PATCH, the API version the Azure CLI uses) and waits for the upgrade, about a minute.
  • Waits until the MongoDB endpoint accepts mongosh connections: on an account that already held data, the endpoint went on serving 3.6 for several minutes after Azure Resource Manager reported 7.0.
  • Upserts the same nine activities as documents {_id, username, activity, timestamp} with mongosh, setting the fields only on insert, so a re-run leaves existing documents alone. The filter holds the shard key, username. The activities are then queried back.
• The four README.md files: the 01-deploy-resources.sh row says what the script seeds and which tool it needs on the host (curl and openssl, or mongosh), and why the MongoDB script sets the server version itself.
• .github/workflows/run-samples.yml: installs mongosh 2.14.1, pinned with its SHA-256, on the Linux runners for the MongoDB sample. The Windows runner image ships mongosh 2.14.1 already.

The Python and .NET 01-deploy-resources.sh of each sample stay identical.

Tests

Each language ran on both targets with the same scripts; the test copies differed only in PREFIX (and PORT, since 8080 was taken on the host).

• LocalStack for Azure (localstack/localstack-azure:latest, 2026.11.0.dev842):
  • NoSQL: the first run inserted 9 items (HTTP 201) and the query listed 9; a second Python run and a .NET run found all 9 (409) and inserted none.
  • MongoDB: the account came up at 3.6, the script upgraded it to 7.0, the endpoint accepted mongosh at once, 9 activities were inserted and listed; the re-runs inserted none.
  • 03-run-docker-container.sh: all four apps answer /health with ok and list the 9 seeded activities.
• Azure (italynorth):
  • NoSQL: 9 items inserted with the signed requests, the query listed 9, the re-runs inserted none.
  • MongoDB, new account (.NET copy): created at 3.6, upgraded to 7.0 in about 35 seconds, 9 activities inserted and listed.
  • MongoDB, account already holding a collection (Python copy): upgraded to 7.0, but its endpoint kept reporting wire version 6 for several minutes, which made the seed fail before the wait existed; with the wait, 9 activities inserted and listed, and the re-runs inserted none.
  • 03-run-docker-container.sh: all four apps answer /health with ok and list the 9 seeded activities.
  • Both resource groups were deleted afterwards.
• bash -n passes on the four scripts. The mongosh release's SHA-256 was computed from the downloaded tarball, and the path of the binary in it checked; the step itself runs in this pull request's Samples CI.

Related

• localstack/localstack-pro pull request 10406 and aks-samples Cosmos DB NoSQL samples: no LocalStack CA, the endpoint is publicly trusted #55: the Cosmos DB for NoSQL endpoint the seed calls is served with the public certificate since then, so curl verifies it with its default trust store.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FvNuJLfY2KkMwaymfFnz7R